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1 System and Method For Selectable Funding of 

2 Electronic Transactions 

3 

4 CROSS REFERENCE TO RELATED APPLICATIONS 

5 The subject matter of this application is related to the subject matter of 

6 provisional application U.S. Serial No. 60/245,665 filed November 6, 2000, 

7 assigned or under obligation of assignment to the same entity as this 

8 application, from which application priority is claimed, and which application 

9 is incorporated by reference. 

10 FIELD OF THE INVENTION 

11 The invention relates generally to electronic commerce, and more 

12 particularly to a system and method for selectively scheduling payment and 

13 other transactions such as bill pay from a variety of sources and according to 

14 selectable schedules, while optimizing those transactions for least cost and 

15 other benefits to the payment enabler, consumer or others. 

16 BACKGROUND OF THE INVENTION 

17 Electronic commerce, such as personal banking via the Internet, has 

18 become increasingly popular. Many electronic banking applications enable a 

19 user to perform banking related transactions from home, such as through a 

20 personal computer, browser-equipped cellular phone, electronic wallet (both 

21 client side and server side) or other client device. Using the client device, a 

22 user may manipulate a graphical user interface to transfer funds between 
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1 accounts, direct a wire payment to a third party, redeem securities or perform 

2 other transaction functions. 

3 Electronic banking may however suffer from the drawback that it is 

4 difficult for a user to manipulate and move funds when and how the person 

5 desires. Some systems require a user to access multiple graphic user interface 

6 screens to effectuate the transfer of money, even from just one source account 

7 to just one recipient. These access requirements, possibly including repeated 

8 logins, may lengthen the process and cause user confusion, thereby 

9 discouraging a user from accessing the service. 

10 Electronic banking may also suffer the drawback of defaulting to a 

11 payment mechanism which may not be the most efficient or cost effective 

12 manner for achieving various transactions. For example, some methods for 

13 transferring funds may be more expensive than others. A balance transfer 

14 transaction using a credit card account as a source of payment which is 

15 executed at a cost of, for example, 3% of balance may be more expensive than 

16 an ACH transfer, or transmitting a personal or certified check or postal or bank 

17 money order to satisfy the same credit card or other bill. 

18 The host financial institution, acting as the payment enabler to the 

19 transaction, may therefore absorb different internal costs depending on the 

20 payment mechanism chosen by the user, or to which the transaction defaults. 

21 The consumer may in cases see those differing transaction costs reflected in 

22 different fees charged to them. 

23 Moreover some financial institutions, from the point of view of internal 

24 operations, consider certain categories of funds transfer, including the 

2 
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1 Automated Clearing House (ACH) and wire transfer, as risky since 

2 authenticating the identity of the customer may be difficult or impossible. 

3 However security criteria may not always* be factored into transaction defaults 

4 or rules. Other parameters, such as contractual obligations such as minimums 

5 with different payment providers, possible volume discounts, tiered rewards 

6 thresholds and others may not be taken into account in the ordinary routing of 

7 transactions. 

8 The consumer, business or other payment initiator for their part may 

9 need to be aware of various payment mechanisms and the costs associated with 

10 each method of delivering payment to determine the most cost-effective way of 

11 transmitting funds, without assistance from the electronic payment system 

12 itself. 

13 Fulfillment services may therefore be more expensive for providers and 

14 users than necessary, and less expedient or secure than they could be. 

15 Further, many financial institutions such as banks, credit card 

16 companies, mortgage companies, securities houses and other entities contract 

17 with a single third party bill payment provider to have bills presented and paid 

18 on their behalf using bill pay platforms. Typically the Web site or telephone 

19 bill pay products are branded by the provider to represent the financial 

20 institution. In some cases the financial institution maintains the user interface 

21 but in other cases, the bill payment provider provides the user interface. 

22 Examples of bill payment providers include CheckFree, Spectrum, ePrinceton 

23 Telecom, M&I and others. 
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1 In addition, in most cases only one bill payment provider can be used at 

2 one time or by one customer due to a financial institution's inability to provide 

3 a consolidated view of the various bill payment and transfer methods. Usage of 

4 multiple bill payment services and transfers may cause further confusion for the 

5 customer, and the institution's customer care team. 

6 An integrated, programmable and optimizing technique for managing 

7 various fund transfers and other transaction, and providing tracking to the 

8 customer and customer service representative, is not available. Other 

9 drawbacks exist. 
10 

11 SUMMARY OF THE INVENTION 

12 The invention overcoming these and other problems in the art relates in 

13 one regard to a system and method for selectable funding or adaptable routing 

14 of transactions, including electronic and other transactions, which enables a 

15 payment initiator such as a consumer, business or government entity to select, 

16 schedule, maintain and optimize the timing and technique used to effect various 

17 payments, including to schedule bill payments on time and at least cost to the 

18 payment enabler or payment initiator. 

19 In one regard, the invention may permit a payment initiator to 

20 transparently enjoy the benefits of optimization, once payment schedules and 

21 other data are input, since the system arranges for the best available delivery 

22 mechanism to satisfy the scheduled payment obligations automatically. The 

23 invention may furthermore achieve economies for the bank or other 

24 participating institution, since payment sourcing and routing may be optimized 
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1 at the level of the payment enabler, as well as for the consumer. The invention 

2 in another regard may increase the range and flexibility of available funding 

3 sources, as well as recipients, using an integrated mediation engine. 

.4 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

6 Figure 1 is a schematic representation of a system for transferring funds 

7 according to an embodiment of the invention. 

8 Figure 2 is a flowchart illustrating funds processing according to an 

9 embodiment of the invention. 

10 Figure 3 illustrates a user interface to schedule and manage payment 

1 1 transactions according to an embodiment of the invention. 

12 Figure 4 illustrates optimization processing according to an embodiment 

13 of the invention. 

14 

15 DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

16 As illustrated in Figure 1, the payment system 100 of the invention in 

17 one regard provide a consumer, business or other payment initiator with an 

18 integrated interface with which to manage the programmable payment of a 

19 number of types of bill and other payments from diverse sources of funds on an 

20 optimized basis. 

21 For instance, using the payment system 100 of the invention the 

22 payment initiator may schedule electronic, paper or other payments to, for 

5 
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1 instance, a mortgage account, a car finance or lease account, credit card or 

2 merchant card accounts, utility accounts, contribution accounts such as 401(k) 

3 or educational or charitable accounts, or other accounts or recipients through an 

4 integrated and relatively streamlined interface. The invention in another regard 

5 may interface to conventional software packages, such as personal finance 

6 managers (PFMs) or others as a front end, to increase ease of use for 

7 consumers, businesses and other payment initiators familiar with those tools. 

8 The payment initiator may schedule those funds transfers from a variety 

9 of source accounts, such as checking or other demand deposit accounts 

10 (DDAs), money market funds, securities accounts, stored value accounts, other 

11 credit card accounts, currency accounts, overdraft lines of credit, micro 

12 payment accounts, lines or credit or other accounts or facilities which may act 

13 as a source of funds. 

14 The payment system 100 of the invention in an embodiment provides a 

15 flexible, one-view interface to all of the possible sources and recipients of one- 

16 time or recurring funds transfers. The payment initiator may therefore view 

17 and manage all their transactions without resorting to multiple platforms or 

18 performing multiple authentications. 

19 In another regard, the payment system 100 of the invention may 

20 automatically drive transactions from source funds to recipient accounts using 

21 the most efficient transfer mechanism available for the payment the user has 

22 selected. For instance, a payment initiator may select to have a payment made 

23 on a credit card account by way of a check or other payment or instrument 
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1 drawn on a deposit account by a certain day of the month while maintaining 

2 funds availability for the longest possible time. 

3 The payment system 100 of the invention may then analyze the costs 

4 and delivery timeline for that fund transfer to effectuate the most optimal 

5 available transfer. Factors taken into account to optimize the transaction may 

6 include the identity of the payee as the funding destination (such as a credit 

7 card provider), the delivery timeline (such as the number of days until the 

8 payment must be made), the funding source (such as a financial institution 

9 providing a direct deposit account), and any third party providers having a 

10 relationship with the funding source, including identifying those that offer 

1 1 rewards or other benefits accrue through that channel. 

12 Other optimization factors or rules may include costs to the payment 

13 initiator and to the bank or other host entity, contractual or other account 

14 minimums, the reliability of the payment channel, dollar amount (e.g. 

15 micropayments or macropayments), any discounts for quantity of transactions 

16 or amounts of transactions, and other rules-based intelligence. In an 

17 embodiment of the invention, the payment system 100 may also aggregate 

18 multiple payment transactions to increase efficiency, such as for instance 

19 aggregating all of one payment initiator's payments to a single large bank for a 

20 month, or the transactions of multiple customers to realize rewards leverage, 

21 economies of scale or other benefits. 

22 Other factors accounted for in performing an optimized calculation 

23 include the type or category of payee, payment thresholds, tiered rewards or 

24 other graduated benefits, the type and nature of any intermediary account used 

7 
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1 to effect the transaction, and others. Two or more of a payment source, 

2 intermediary and a payee for instance may be identified as both belonging to 

3 the same association or network, permitting efficiencies to be realized when 

4 remaining within the association or network. The factors and rules taken into 

5 account may be modified over time to reflect changing market conditions, 

6 refinements to the transaction model and other evolving criteria. 

7 As a result, the payment system 100 may determine that the funding 

8 destination, such as a revolving credit account provider, is a member of a third 

9 party association with which the funding source subscribes or otherwise has 

10 access to, such as the commercially available Spectrum service. As a result, the 

1 1 cost of the scheduled payment may be reduced by routing the payment through 

12 the common association (such as Spectrum or others) with the payee, rather 

13 than routing the transaction through a default payment provider outside the 

14 association. 

15 By contrast, the payment system 100 may determine that the payee 

16 account and the funding source, or the host entity itself, are part of the same 

17 organization. In this instance, an internal transfer may be determined to be the 

18 most cost efficient mechanism for effecting payment, without resort to any 

19 external payment network. Costs may be reduced for both payment initiator 

20 and payment enabler, in that scenario. 

21 In operation, as illustrated in Figure 1, consumers, businesses, 

22 government entities and other payment initiators may use one or more clients 

23 105 to access the payment system 100 through network 102, for instance 

8 
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1 through multiple connector providers (CPs) 110 such as Internet service 

2 providers (ISPs) or others. 

3 According to an embodiment of the invention, the clients 105 may be or 

4 include, for instance, a personal computer running Microsoft Windows™ 9x, 

5 Millenium™, NT™, 2000 or XP™, Windows™CE™, MacOS™, PalmOS™, 

6 Unix, Linux, Solaris ™, OS/2 ™'. Clients 105 may also be or include a 

7 network-enabled appliance such as a WebTV™ unit, radio-enabled Palm™ 

8 Pilot or similar unit, a set-top box, a networkable game-playing console such as 

9 Sony Playstation™, Sega Dreamcast™ or Microsoft XBox™, a browser- 

10 equipped or other network-enabled cellular telephone, an automated teller 

11 machine (ATM), an electronic wallet (client side or server side), or other 

12 TCP/IP client or other device, or a stand-alone Website offering. Client 105 

13 may yet further be, include or interface to character recognition platforms or 

14 voice recognition platforms or other channels. 

15 Network 102 may be, include or interface to any one or more of, for 

16 instance, the Internet, an intranet, a LAN (Local Area Network), a WAN (Wide 

17 Area Network) a digital Tl, T3, El or E3 line, DSL (Digital Subscriber Line) 

18 connection, an Ethernet connection, an ISDN (Integrated Services Digital 

19 Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem 

20 connection, a cable modem, an ATM (Asynchronous Transfer Mode) 

21 connection, or other connection. Network 102 may furthermore be, include or 

22 interface to any one or more of a WAP (Wireless Application Protocol) link, a 

23 GPRS (General Packet Radio Service) link, a GSM (Global System for Mobile 

24 Communication) link, a CDMA (Code Division Multiple Access) or TDMA 

9 
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1 (Time Division Multiple Access) link such as a cellular phone channel, a GPS 

2 (Global Positioning System) link, CDPD (cellular digital packet data), a RIM 

3 (Research in Motion, Limited) duplex paging type device, a Bluetooth, 

4 BlueTeeth or WhiteTooth radio link, or an IEEE 802.11 (Wi-Fi)-based radio 

5 frequency link. Network 102 may yet further be, include or interface to any 

6 other wired or wireless, digital or analog interface or connection. 

7 Connection provider 1 10 may be or include a provider that connects the 

8 requesters to the network 102. For example, connection provider 110 may be 

9 or include an internet service provider (ISP), a virtual private network (VPN), 

10 an intranet, a dial-up access device such as a modem, or other manner of 

1 1 connecting to network 1 02. 

12 Figure 1 illustrates four clients 105 connected to network 102 through 

13 two connection providers 110, but it will be understood that in practice less or 

14 significantly more users may be connected or connectable to payment system 

15 100 than shown in Fig. 1, including through one or more connection providers 

16 110. 

17 The payment system 100 may include a processor 112, which may also 

18 have a connection to the network 102. Processor 112 may communicate with 

19 one or more data storage modules 1 14, discussed in more detail below. 

20 Each of clients 105 used by payment initiators to manipulate payments 

21 and accounts may contain a processor module 104, a display module 108, and a 

22 user interface module 106. Each of clients 105 may have at least one user 

23 interface module 106 for interacting and controlling the computer. The user 

24 interface module 106 may be, include or interface to one or more of a 

10 
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1 keyboard, joystick, touchpad, mouse, scanner or similar device or combination 

2 of devices. In an embodiment, the display module 108 may be or include a 

3 graphical user interface (GUI) to input data and conduct other transaction tasks. 

4 The processor 112 may maintain a connection to the network 102 

5 through transmitter module 1 18 and receiver module 120. Transmitter module 

6 118 and receiver module 120 may be or include conventional devices which 

7 enable processor 112 to interact with network 102. According to an 

8 embodiment of the invention, transmitter module 118 and receiver module 120 

9 may be integral with processor 112. The connection to network 102 by 

10 processor 1 12 and clients 105 may be a broadband connection, such as through 

11 a Tl or T3 line, a cable connection, a telephone line connection, DSL 

12 connection, or other type connection. 

13 Processor 112 functions to communicate with clients 105 and permit 

14 clients 105s to interact with each other in connection with transaction services, 

15 messaging services and other services which may be provided through payment 

16 system 100. 

17 The processor 112 may communicate with a number of data storage 

18 modules 114. Each of data storage module 114s may stores various 

19 information associated with the payment platform, including administrator data, 

20 received instructions, transaction logs or other files or other information. 

21 According to an embodiment of the invention, each of data storage module 

22 114s may be located on one or more data storage devices, where the data 

23 storage devices are combined or separate from processor 112. Each of data 

24 storage modules 114 may be, include or interface to, for example, the Oracle™ 

11 
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1 relational database sold commercially by Oracle Corp. Other databases, such 

2 as Informix™, DB2 (Database 2), Sybase™ or other data storage or query 

3 formats, platforms or resources such as OLAP (On Line Analytical Processing), 

4 SQL (Standard Query Language), a storage area network (SAN), Microsoft 

5 Access™ or others may also be used, incorporated or accessed in the invention. 

6 Each of data storage modules 114 may be supported by server or other 

7 resources, and may in embodiments include redundancy, such as a redundant 

8 array of independent disks (RAID), for data protection. 

9 While a supporting architecture has been described, it will be 

10 understood that other architectures could support the operation of payment 

11 system 100. In general, the payment system 100 is designed to allow financial 

12 and other payment initiators to be able to pay bills and transfer funds when and 

13 where they want, in a selectable, integrated and optimized manner. 

14 The payment system 100 of the invention in one regard permits a 

15 financial institution or otrler payment enabler to consolidate and aggregate the 

16 movement of money via the Internet, at in-person branch visits, at retail or 

17 other kiosks, over the telephone or other network and provide one view to the 

18 payment initiator. In an embodiment, a view may also be provided to a call 

19 center representative. According to an embodiment of the invention, the 

20 payment initiator may be provided with a cumulative total of bills paid and 

21 transfers made both in and out for a term defined by the payment initiator (e.g.. 

22 daily, weekly, monthly, quarterly, annually). Optimizations may be executed 

23 on scheduled transactions to minimize cost or maximize float, or manage other 

24 variables. 

12 



PATENT 

Attorney Docket No. : 47004.000 1 1 5 



1 For example, parameters can be established to allow the payment 

2 initiator to automatically pay a bill and/or transfer funds without further any 

3 involvement based on desired payment date, payment recipient such as a 

4 merchant, bank or other account holder, the dollar amount of the transaction, 

5 the source of the transaction funds, and other variables. By way of example, a 

6 payment initiator may designate that the electricity bill should be paid on the 

7 due date for a given month, to avoid a significant late fee by the utility or other 

8 entity or a surcharge applied by commercial wire delivery services. Same-day 

9 payment may be programmed for other accounts with timing sensitivity, for 

10 instance mortgage payments. The payments scheduled according to various 

11 tiers of timing may, in embodiments of the invention, be offered to the 

12 consumer or other payment initiator at different levels of costs, depending on 

13 urgency. 

14 The payment system 100 may also allow the payment initiator to select 

15 a prospective time frame in which the payment shall be made. The time frame 

16 may be, for example, besides the same day, the next day, next week, specified 

17 date, an offset from a bill date (e.g. 2 days before due), or other designated 

18 payment windows. The payment system 100 may have an open architecture 

19 that supports various interfaces between a server or Web site and host systems 

20 such as ACH/NACHA, Wire, RPS, OFX or other protocols. 

21 The ACH network, or automated clearing house, as administered by the 

22 NACHA, may for example provide a payment initiator with the ability to 

23 transfer funds over the ACH network. Wire transfers, which transfer funds 

24 immediately, but at a significantly greater cost than the ACH network, may also 

13 
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1 be designated by a payment initiator. A remittance process system (RPS) 

2 protocol, designed by MasterCard®, or an open financial exchange (OFX) 

3 protocol, designed by Intuit, CheckFree, and Microsoft, may also be used to 

4 transfer financial information. Other protocols may be employed. 

5 According to an embodiment of the invention, an optimization function 

6 may be used by payment system 100 to optimize the transfer mechanisms for 

7 transferring funds. By way of example, Thursday, a payment initiator may 

8 instruct that her funds be transferred for bill payment by Friday. The payment 

9 system 1 00 may permit that type of short turnaround transaction to take place 

10 for instance by, in embodiments, allowing the consumer or other payment 

11 initiator to make use of payment mechanisms not generally available to 

12 consumers and others for rapid transfers, such as wire transfers or ACH 

13 transactions. The payment enabler may assign different service charges to 

14 different urgencies of payment. 

15 The payment system 100 may determine what method of transfer will 

16 achieve the results requested by the payment initiator, at the lowest cost to the 

17 payment enabler or while satisfying other criteria for optimal results. Other 

18 methods of optimization may also be used, for instance by utilizing rules based 

19 intelligence. Variables included in the optimization model may include, for 

20 example, classification of the funding mechanism, payee, dollar amount (for 

21 example micro payments, macro payments and others) and other rules such as 

22 time of day; lead time, dollar amount, contractual minimums, reliability, 

23 pricing, detecting and taking advantage of intra-entity transfers and others. A 

24 flowchart of transaction processing according to an embodiment of the 

14 
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1 invention is illustrated in Figure 2. In step 200, processing of new customers 

2 (not preexisting) begins, at which point the customer, such as a consumer, a 

3 qualified business or other payment initiator may register for a new account 

4 enabled for payment system 100. Registration may be by in-person registration 

5 at a branch or other facility, Web site, telephone, any of the other network 

6 techniques illustrated in Figure 1, or otherwise. In step 202, the customer may 

7 undergo a standard screening process, with possible further screening for the 

8 integrated payment services of the invention. The customer may sign up for 

9 one or more services, such as credit card, DDA, mutual fund, home equity, or 

10 others. 

11 After identification, addressing and other information is gathered, at 

12 step 204 the host bank or other entity may decide which transfer mechanisms to 

13 allow to the customer depending on the customer's request, the risk the entity 

14 perceives and what the entity assesses the customer actually needs. If approval 

15 is received at step 206, the customer may be directed to an existing customer 

16 flow, such as that described below. If approval is declined at step 208, then the 

17 customer may be provided with a reduced or modified set of automated features 

18 at step 260. 

19 In step 220, an existing customer of a financial institution or other host 

20 entity who desires access to payment system 100 may likewise be set up to 

21 enjoy an integrated method of accessing payment vehicles instead of having to 

22 deal with a differing pipelines of instruments. Using a client 105, the customer 

23 may authorize themselves at step 222 to a Web page, VRU, bank teller, CSR or 

24 other channel. The customer may then select the type of payment and the 

15 
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1 urgency, date, cost, rewards allocations or other factors at step 224. For 

2 example, a customer may want to pay a corporate credit card bill from a travel 

3 bank account. The payment initiator may direct and authorize the payment and 

4 choose to have the bill paid the day before the date it is due. 

5 The payment initiator may permit the payment system 100 to optimize 

6 the routing and timing of that payment. If the payment initiator chooses to key 

7 the payment to a date function to avoid late fees, the payment system 100 may 

8 select the best method that will assure that funds are presented on time at the 

9 least cost, while also deferring the payment until, for example, 3 days before 

10 hand to increase the float or interest on money in a source checking account. 

1 1 On the other hand, if a payment initiator prefers to program the payment 

12 system to pay bills on the day they are received to ensure they are satisfied with 

13 time to spare, the payment system 100 may generate instructions for prompt 

14 payment at the lowest transaction fee available, benefiting the payment enabler, 

1 5 payment initiator or both. 

16 As a further example, if a payment initiator has procrastinated and is 

17 near to a payment due date, they may authorize an immediate and higher cost 

18 payment to ensure payment is received by any due date, such as a mortgage or 

19 credit card due date. Depending on the my selection of payment type and 

20 urgency, in step 226 the payment system 100 may determines whether 

21 additional authorization is needed to complete the scheduled transaction. 

22 Factors taken into account for approval may include the length of time that a 

23 payment initiator has been with the bank or other host entity, the number of 
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1 accounts or assets maintained by the payment initiator, risk factors such as 

2 credit history or NSF history, or others. 

3 At this point, the bank or other host entity as payment enabler may also 

4 determine whether the transaction is possible. For instance, a payment initiator 

5 may desire to send a payment for a child's college tuition. The payment 

6 initiator may want to draw $3000 from a checking account, $4000 from a home 

7 equity account, and sell $3000 from a stock brokerage account to satisfy a 

8 $10,000 school payment due. However, if the payment initiator eagerly 

9 pursues bonus point or other benefits, they may want to use a participating 

10 credit card so the points can be used to fly the college student home over a 

1 1 holiday. 

12 At 226, the payment system 100 may permit the payment initiator to 

13 register these variables in a stored profile or otherwise to optimize the tuition 

14 payment according to date, amount, float, bonus points or other rewards or 

15 parameters. The bank or other host entity may determine if the payment 

16 initiator has sufficient available funds at step 228, and may suggest different 

17 solutions to the payments based on the payment initiator's profile. Once 

18 approved, the payment system 100 may determine the most efficient manner 

19 for payment in step 230. In step 232, the request for transaction approval may 

20 be transparently processed by the payment system 100. While the processing 

21 may be transparent to the payment initiator, the payment system 100 may 

22 provide a GUI tracking display 136 for customer service representative (CSR) 

23 of the bank or other host entity. If there is a question on how the item was 

24 processed, the CSR can pull up the transaction and see details in an integrated 

17 
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1 view. At step 234, the payment system 100 may notify the payment initiator of 

2 a completed or scheduled transfer via a Web page message, e-mail notification, 

3 on a statement mailed to the payment initiator or other channel. 

4 In the case of a payment initiator seeking a payment transaction who 

5 may not be a preexisting customer of the bank or other host entity, in step 260 a 

6 person having a separately branded credit card account may wish to pay a bill 

7 on that account using a check drawn on a third party bank. The payment 

8 initiator may register for access to the payment system 100 with those or other 

9 accounts. In step 262, the host entity may authenticate the offered accounts to 

10 verify that the accounts actually exist. If they do and the customer is eligible to 

11 be set up, the host entity may inform the payment initiator which payment 

12 options he or she is eligible for to fulfill their desired transaction. 

13 For instance, the host entity may not allow a non-customer to execute a 

14 wire transaction because once the funds are transferred, there is no way to 

15 reverse the transaction. At step 266, the host entity may therefore request 

16 authentication information to set up the process, as well as optionally offer the 

17 customer accounts with the host entity to increase payment capabilities. If the 

18 payment initiator elects to open an account with the host entity, processing may 

19 proceed to step 206. 

20 Assuming that the payment initiator wants to access the payment system 

21 100 with their existing accounts, the available options may be made to depend 

22 on the level of risk the host entity perceives. At step 268, the payment initiator 

23 may for instance request a transfer of money from their checking account to 

24 pay their credit account. The host entity may validate the funds availability at 
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1 step 270. At step 272, the payment system 100 may determine the most 

2 efficient manner to transfer the funds, but selecting among the reduced set of 

3 available payment vehicles. At step 274, the funds may be moved into an 

4 intermediary account, or pass directly through to the payee. At step 276, the 

5 payment initiator may be notified of the completed payment or scheduled 

6 payment via a Web page message, e-mail, monthly statement, page, or other 

7 channel.An illustrative interface for use by a consumer, business or other 

8 payment initiator is shown in Figure 3, in which a GUI 302 is displayed. GUI 

9 302 may include pay- from selector box 304 to identify accounts from which to 

10 pay bills, a payee selector box 306 to identity the recipient of the payment, a 

11 schedule selector box 308 to enter or select desired dates, date ranges or date 

12 offsets by which to effectuate payments, and an optimization selector box 310 

13 with which to select one or more variables by which the transaction will be 

14 optimized including cost, schedule, rewards and other criteria. Other functions, 

15 such as account registration and other functions, may be provided. 

16 An optimization process which may be employed according to an 

17 embodiment of the invention is illustrated in Figure 4. In step 402, a payment 

18 request is received. In step 404, a test of the funding source's affiliations may 

19 be made, for instance by running a query against a corporate database 460. The 

20 corporate database 460 may contain information describing various 

21 corporate/merchant hierarchies and interrelationships, for instance indicating 

22 that FirstUSA Bank NA is a wholly owned subsidiary of Bank One Corp. 

23 Other affiliations are possible. 

19 
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1 In step 406, a test may be made of affiliations of the payee of the 

2 transaction, for instance by consulting corporate database 460 or other 

3 resources. In either of step 404 and 406, information regarding the detected 

4 affiliations may be stored to memory 462, such as a relational database, data 

5 cache or other resource. In step 408, a test may be made whether the payment 

6 source and payee indicate a common affiliation, such as a parent/subsidiary or 

7 other relationship. 

8 In step 410, a test may be made whether the payee participates in a third 

9 party association that may have an effect on the transaction. This may be done 

10 by running a query against an association database 464 or other resource, for 

11 instance storing all participants in an electronic transaction network such as 

12 Spectrum™, ACH or others. In step 412, a set of possible funding mechanisms 

13 to fulfill the transaction may be generated, for instance indicated all transfer 

14 types that will fulfill minimal scheduling requirements. This may be done by 

15 running a query on funding mechanism database 466, which may include 

16 descriptive fields such as cost, eligibility criteria, time frame, risk level, 

17 security, reliability rating and others. 

18 In step 414 an optimal funding mechanism under all the parameters of 

19 the transaction may be generated. In so doing, a business rules database 468 

20 may be consulted, to determine whether factors such as contractual minimums, 

21 volume discounts, micro payments or other special funds processing, tiered 

22 thresholds or other rules or intelligence may be stored. The business rules may 

23 be modified over time to reflect updated market conditions or refinements to 
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1 the processing model. In step 416, the optimal transaction may be executed. In 

2 various other of the steps, data may be stored to memory 462 as appropriate. 

3 The foregoing description of the system and method of the invention is 

4 illustrative, and variations in configuration and implementation will occur to 

5 persons skilled in the art. For instance, while the invention has generally been 

6 described in terms of a processor 116 managing the scheduling and 

7 optimization of transactions over a network 102, in embodiments the processor 

8 116 or other intelligent device may be self-contained, for instance in a desktop 

9 machine, for instance running a so-called fat client. 

10 In other embodiments, the input interface to the payment initiator may 

11 be by way of a telephone connection, for instance via a call center facility or a 

12 voice response unit (VRU) enabled to communicate with data storage 1 14 or 

13 other elements. Yet further, while the invention has generally been described 

14 in terms of scheduled transactions in which the presented bill, payment source 

15 and payee all deal in the same currency, in embodiments currency conversions 

16 may be performed at appropriate stages of the transaction. Yet further, while 

17 the invention has generally been described in terms of electronic fulfillment of 

18 scheduled bills, check or other hard copy or other types of payment may be 

19 optimized and delivered according to the invention. The scope of the invention 

20 is accordingly intended to be limited only by the following claims. 
21 
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